When verifying software, it is often necessary to re-run the same or similar simulations numerous times to identify, understand and resolve problems in the software. For large or complex software systems, such as simulation programs, arriving at a point of interest (e.g., the point where a bug manifests itself or is fixed, or where the user wishes to observe the system's performance) may take a significant amount of time. This is especially true when the simulation represents intricate hardware devices with timing requirements that must be modeled accurately.
The degree of accuracy required can cause software simulations of hardware to run slowly, and create significant delays between the start of a simulation and arriving at the point of interest. Even when using simulation hardware, it is not uncommon to encounter differences in speed between the actual electronic device and the simulation by factors on the order of tens of thousands to millions. For large simulations, many software simulators can execute at a rate between 1 Hz and 100 Hz, depending on the simulator and the electronic device being simulated, whereas it is not uncommon for the physical device to run at clock speeds of 500 MHz or more. This means that it could take weeks or even months to simulate one second of the operation of an electronic device. Even a hardware-based simulator, which may execute a simulation at a rate of 1000 Hz to 1 MHz, may still be hundreds or thousands of times slower than the actual device.
Simulations may also be used to debug software. However, debugging software exclusively on a simulator can be problematic. As noted above, running simulations, and hence the debugging process, may be very time consuming. That is, if the problem(s) appear after running the software program on hardware for a significant time such as several minutes or hours, the same problem(s) may not be encountered on a simulator for a translated significant time of hours or days.
Many simulators attempt to overcome this speed limitation by implementing a save-and-restore methodology that allows a complete simulation state to be saved at any point during execution of the simulation. This saved state can then be loaded at a later time to avoid re-execution of the cycles that preceded the saved state. This technique is often used when a long boot process executes prior to the execution or use of other software components. Such methods have a fundamental limitation in that every component in the system (including the software being debugged) must support the state-saving feature. Further, in order to debug a system using this technique, it is necessary to save the system state before the problem occurs. Since a system error may occur long before a problem manifests itself as a visible symptom, however, detecting the correct point in time to save a system state requires non-trivial effort.
Thus, software simulators may execute slowly and may be limited in their ability to exactly replicate hardware functionality. Accordingly, a need exists for the ability to perform detailed software debugging less expensively and faster than current methods, systems and devices allow.